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[57] ABSTRACT 

The invention features receiving encrypted network packets 
sent over a network at a network interface computer, and 
passing the encrypted network packets to a computer on an 
internal network. 

The invention also features receiving encrypted network 
packets at a first computer over a network from a second 
computer, examining a field in each network packet to 
determine which of a plurality of encryption algorithms was 
used to encrypt the network packet, and decrypting the 
network packet in accordance with the determined encryp- 
tion algorithm. 

The invention further features receiving network packets 
sent over a network, determining which virtual tunnel each 
network packet was sent over, and routing each network 
packet to a destination computer in accordance with the 
determined virtual tunnel. 

The invention features encrypting network packets at a 
computer connected to an internal network, passing the 
encrypted network packet over the internal network to a 
public network interface computer, and passing the 
encrypted network packet over a public network connected 
to the network interface computer. 
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TRANSFERRING ENCRYPTED PACKETS 
OVER A PUBLIC NETWORK 

This is a continuation of application Ser. No. 08/586,230, 
filed Jan. 16, 1996, now abandoned. 

BACKGROUND 

This invention relates to transferring encrypted packets 
over a public network. 

Referring to FIG. 1, while executing a variety of software 
applications, 10, 12, 14, for example, Telnet 10 or 
Microsoft™, Inc. Word™ 12, computers 16 and 18 may 
exchange data over networks 20, 21, for example, a tele- 
phone company network, a private network, or a public 
network such as the internet or X.25. The applications 
communicate using network protocols 22, 24, 26, for 
example, transmission control protocol/internet protocol 
(TCP/IP) 22 or internet packet exchange (IPX) 24, through 
application programming interfaces 28, 30, 32. Through 
application programming interfaces 34, 36, 38, the network 
protocols communicate with network drivers 40, 42, 44 to 
direct network interface hardware 46, 48 to transfer data 
over the networks. 

While on a network, data being transmitted, including the 
addresses of the source and destination computers 16, 18, is 
accessible to others who may be monitoring the network. 
For security, the data is often encrypted before being sent on 
the network. 

Referring also to FIG. 2, for additional security, firewall 
computers 16, 18, which have direct access to a network 20 
may be used to prevent unauthorized access to internal/ 
private networks 50, 52. For example, when an internal 
network driver 53 within firewall computer 16 receives data 
from an internal computer 54 that is destined for a computer 
56 on a public network, it encrypts the data and the addresses 
of source computer 54 and destination computer 56. Com- 
puter 16 then prepends to the encrypted data a new IP header 
including its own address as well as the address of a 
destination computer, which may also be a firewall 
computer, e.g., computer 18. 

When a firewall computer receives a network packet from 
the network, it determines whether the transmission is 
authorized. If so, the computer examines the header within 
the packet to determine what encryption algorithm was used 
to encrypt the packet. Using this algorithm and a secret key, 
the computer decrypts the data and addresses of the source 
and destination computers 54, 56 and sends the data to the 
destination computer. If both the source and destination 
computers are firewall computers, the only addresses visible 
(i.e., unencrypted) on the network are those of the firewall 
computers. The addresses of computers on the internal 
networks, and, hence, the internal network topology, are 
hidden. This has been termed "virtual private networking" 
(VPN). 

Encrypting/decrypting data has been performed by com- 
plex security software within applications or, to simplify the 
applications, encrypting/decrypting has been performed 
within the protocol stack of network protocols. 

SUMMARY 

In general, in one aspect, the invention features a method 
of handling network packets. Encrypted network packets are 
received from the network at a network interface computer 
and passed to a computer on an internal network. 

Implementations of the invention may include one or 
more of the following features. Before passing the encrypted 
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network packets to the computer on the internal network, the 
destination computer for each encrypted network packet is 
determined. Determining the destination computer may 
include determining whether a source computer that sent 

5 each encrypted network packet is authorized to send 
encrypted network packets to the destination computer. 
Determining the destination computer may also include 
examining a field in a header of the network packet, and the 
field may correspond to a virtual network tunnel. 

io An encrypted network packet may be passed to the 
computer on the internal network if the computer on the 
internal network is determined to be the destination com- 
puter. Instead, the encrypted network packet may be 
decrypted at the network interface computer when the 

15 network interface computer is determined to be the desti- 
nation computer. Network packets decrypted by the network 
interface computer may be passed to a computer on an 
internal network. 

The method may also include encrypting network packets 

20 and sending the encrypted network packets from the net- 
work interface computer to the network. The computer on 
the internal network may encrypt the network packets, and 
the method may further include passing the encrypted net- 
work packets to the network interface computer. The net- 

25 work interface computer may be a firewall computer, and the 
network may be a public network. 

In general, in another aspect, the invention features 
receiving encrypted network packets at a first computer over 
a network from a second computer, and examining a field in 

30 each network packet to determine which of a plurality of 
encryption algorithms was used to encrypt the network 
packet. The network packet is then decrypted in accordance 
with the determined encryption algorithm. 

35 Implementations of the invention may include one or 
more of the following features. The field may be examined 
to determine a destination computer for each encrypted 
network packet. A determination may be made as to whether 
a source computer that sent each encrypted network packet 

4Q is authorized to send encrypted network packets to the 
destination computer. Encrypted network packets may be 
passed to a computer on an internal network when the 
destination computer is determined to be the computer on 
the internal network. The network packets may be decrypted 

45 when the destination computer is determined to be the first 
computer, and the decrypted network packets may be passed 
to a computer on an internal network. The field may corre- 
spond to a virtual network tunnel, and the network may be 
a public network. The first computer may be a firewall 

50 computer. 

In general, in another aspect, the invention features 
receiving network packets over a network, and determining 
which virtual tunnel each network packet was sent over is 
made. Each network packet is then routed to a destination 

55 computer in accordance with the determined virtual tunnel. 
Implementations of the invention may include one or 
more of the following features. Each network packet may be 
decrypted in accordance with the determined virtual tunnel. 
In general, in another aspect, the invention features 

60 encrypting network packets at a computer connected to an 
internal network and passing the network packets over the 
internal network to a network interface computer. The 
network interface computer then passes the encrypted net- 
work packets over a public network. 

65 In general, in another aspect, the invention features 
receiving network packets from a network, and determining 
over which virtual tunnel each network packet was sent. A 
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determination is also made as to whether the source com- Referring to FIGS. 3 and 4, as an example, to send data 

puter that sent each network packet is authorized to send from computer 16 to computer 18 on the internet, Telnet 10 

network packets over the determined virtual tunnel. issues (step 60) a send call to TCP/IP 22 through network 

Implementations of the invention may include one or P™' 0C< ?; AP1 1 2 *' V 1 * f B ^ M ^^includesanetwork packet 62 

more of the following features. Each network packet may be 5 *> • head « 64 J »" d data «■ J 1 * header l ? l " d ™ 

routed to a destination computer in accordance with the »<* ™ the addresses of the source and desta- 

i u *u — *~ -~ nation computers and the type or application that sent the 

determined virtual tunnel when the source computer is data ^ ^ ^ ^ 6g) a ^ caU 

determined to be authorized tQ ^ netWQrk dfiver ^ ^ accordance ^ the 

Advantages of the invention may include one or more of altered road map, issues (step 70) a send call to a security 

the following. Using the policy id field to create virtual 30 network driver (SND) 72. 

tunnels allows a receiving computer to determine both a ^ se^iy network driver issues (step 74) an encapsu- 

packet's encryption algorithm and where the packet should late ca u t0 an encapsulate/decapsulate library 76 through an 

be routed. Multiple tunnels between the same two computers API 77 In one example, the encapsulate/decapsulate library 

allows packets encrypted with different encryption algo- uses the swIPe IP Security Protocol created by J. Ioannidis 

rithms to be sent between the same computers. The virtual of Columbia University and M. Blaze of AT&T™, Inc. 

tunnels permit the encapsulating/decapsulating and wnich ^ described in an Internet Draft dated Dec. 3, 1993 

encrypting/decrypting of network packets to be spread and j ncor porated by reference. Referring also to FIG. 6, the 

across multiple computers. Using the tunnel databases, the encapsulate call generates a new network packet 78 in 

firewall computers may restrict access to particular tunnels accordance with the swIPe protocol. The new packet 

and, in effect, perform packet filtering for each tunnel. 20 mcludes a header 80, a swIPe protocol header 82, and data 

Other advantages and features will become apparent from 84. According to options within the swIPe protocol, header 

the following description and from the claims. 80 may be the original header 64 (FIG. 5), in which case, 

DESCRIPTION ^ ata k °"Si na ^ ^ ata ^» or neac * er 80 mav ^ e a new 

25 header including the address of a source firewall computer, 

FIG. 1 is a block diagram of two computers connected e.g., computer 16 (FIG. 2), and a destination computer 

together through two networks. which may also be a firewall computer, e.g., 18. Where 

FIG. 2 is a block diagram of two firewall computers and header 80 is a new header, data 84 includes the entire 

networks. original network packet 62 (FIG. 5). 

FIG. 3 is a block diagram of a computer including a 30 After encapsulating the network packet, the security net- 
security network driver. work driver issues (step 88, FIG. 4) an encryption call to an 
FIG. 4 is a flow chart of encapsulation and encryption. encryption/decryption library 90 (FIG. 3) through an API 91. 

t-t/-o rj/: uiij- f*i i* Library 90 encrypts a portion 92 of the encapsulated net- 

FIGS. 5 and 6 are block diagrams or network packets. , J . . y,. 4 OA , , r \ n , 

a r work packet including data 84 and part of swIPe protocol 

FIG. 7 is a flow chart of decryption and decapsulation. ^ Qeader 82 Header 8Q ^ Q q fc not encrypted. Thus, if, 

FIG. 8 is a block diagram of virtual tunnels. according to options within the swIPe protocol, header 80 is 
FIG. 9 is a block diagram of a computer network. the original header 64 (FIG. 5), then the addresses of the 
FIG. 10 is a flow chart of tunnel record generation. source and destination computers are visible on the internet. 
FIG. 11 is a flow chart of tunnel record updating. On the other hand, if header 80 is a new header including the 
As seen in FIG. 3, security network driver software 72 is 4 o addresses of firewall computers, then the addresses of inter- 
inserted between network protocol TCP/IP 22 and corre- nd source and destination computers are encrypted and not 
sponding network driver 40. The security network driver visible on the internet. 

encrypts information before it is sent on the network by the Library 90 may be of the type sold by RSA Data 

network driver and decrypts information received from the Security™, Inc. of Redwood City, California and may 

network by the network driver before the information is sent 45 encrypt the data according to an RSA algorithm such as RC2 

to the network protocol. As a result, after choosing a security or RC4 or according to a federal information processing 

network driver with the required security features, users may standard (FIPS) such as data encryption standard (DES). 

freely choose among available applications and network The security network driver then issues (step 94) a send 

protocols regardless of the required level of security and call, including the encapsulated/encrypted network packet, 

regardless of the available encryption/decryption libraries 50 to the API, and the API, in accordance with the altered road 

and without having to compromise their security needs. map, issues (step 96) a send call to a network driver, e.g., 

Moreover, the chosen applications and network protocols network driver 40. The network driver then causes hardware 

need not be modified. To change the level of security, the 46 to transmit (step 98) the encapsulated/encrypted network 

user may simply chose another security network driver or packet on the network. 

modify the current security network driver. 55 Referring to FIGS. 3 and 7, the network drivers of each 

Generally, a computer's operating system software computer 16, 18 (FIGS. 2 and 3) maintain a database of 

defines a "road map" indicating which applications may addresses to which they will respond. For example, when 

communicate with each other. To insert a security network network driver 40 receives (step 100) a properly addressed 

driver between a network protocol and a network driver, the network packet from network 20, the network driver issues 

road map is altered. The vendor of the operating system 60 (step 102) a receive call to corresponding network protocol 

software may make the road map available or the road map API 34. In accordance with the altered road map, the API 

may be determined through observation and testing. Once issues (step 104) a receive call to security network driver 

the road map is altered, functions such as send and receive, (SND) 72 which issues (step 106) an authorization call to 

between the network protocol and the network driver are encapsulate/decapsulate library 76 through API 77. Library 

diverted to the network security driver to encrypt data before 65 7 6 examines the unencrypted portion of swIPe header 82 

it is sent on the network and to decrypt data when it is (FIG. 6) to determine (step 108) whether it is proper. If it is 

received from the network. not proper, an error (step 110) is flagged. 
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If the header 82 is not a swIPe header, then the security 
network driver issues a receive call to the API including the 
unaltered packet. 

If the swIPe header is proper, the security network driver 
issues (step 112) a decryption call to encryption/decryption 
library 90 through API 91. A portion of the unencrypted 
swIPe protocol header includes a policy identification (id) 
field 113. The policy id field indicates the encryption algo- 
rithm used to encrypt the data. Library 90 uses a secret key 
that was previously exchanged between the computers and 
the encryption algorithm to decrypt data 84. 

After decryption, the security network driver issues (step 
114, FIG. 7) a digital signature check call to encapsulate/ 
decapsulate library 76. The swIPe protocol header includes 
a digital signature 86. The digital signature is a unique 
number calculated using the data in the network packet, the 
secret key, and a digital signature algorithm. Library 76 
recalculates the digital signature and compares (step 116) it 
to digital signature 86 in the network packet. If the network 
packet is tampered with during transmission and any data 
within the packet is changed, then the digital signature in the 
packet will not match the digital signature generated by the 
receiving computer and an error (step 118) will be flagged. 

If the signatures match, then the security network driver 
issues (step 120) a receive call to the API which issues (step 
121) a receive call to the TCP/IP network protocol including 
only the original network packet 62 (FIG. 5, data 66 and 
addresses of the source and destination computers 64). If 
(step 122) the network packet is destined for computer 16, 
then TCP/IP issues (step 124) a receive call to an application 
10, 12 and if the network packet is destined for a computer 
on an internal network, e.g., computer 54 (FIG. 2) on 
network 50, then TCP/IP issues (step 126) a receive call to 
internal network driver 53 which then sends (step 128) the 
data to the internal computer. 

Referring to FIG. 8, the policy id field may be used to 
create virtual tunnels 140, 142 between firewall computers 
146, 148 on internet 152. When computer 146 receives a 
network packet, it checks the policy id to determine which 
"runner the packet came through. The runnel indicates the 
type of encryption algorithm used to encrypt the packet. 

Multiple tunnels 140, 142 may connect two computers 
146, 148 and each tunnel may use a different encryption 
algorithm. For example, tunnel 140 may use the RC2 
encryption algorithm from RSAData Security™, Inc. while 
tunnel 142 uses the FIPS DES encryption algorithm. 
Because the RC2 encryption algorithm is less secure and 
requires less computer processing time than the FIPS DES 
standard, users may send a larger number of network packets 
requiring less security over tunnel 140 as opposed to tunnel 
142. Similarly, predetermined groups of users or computers 
may be restricted to sending their packets over particular 
tunnels (effectively attaching a packet filter to each tunnel). 

The tunnel may also indicate where the packet is to be 
sent. Primary firewall computers 16, 18 store information 
about the internal path of each tunnel in a runnel database. 
When computer 146 receives a packet whose policy id 
indicates that the packet came through a tunnel that ends at 
computer 146, e.g., tunnel 142, computer 146 decapsulates 
and decrypts the packet and sends the decrypted packet over 
internal network 154 to the proper destination computer in 
accordance with the decrypted destination address. When 
computer 146 receives a packet whose policy id indicates 
that it came through a tunnel that does not end with 
computer 146, e.g., tunnel 140, computer 146 does not 
decapsulate and decrypt the packet. Instead, computer 146 
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sends the encrypted packet to internal firewall computer 158 
in accordance with the tunnel database. 

Internal firewall computer 158 also has a tunnel database 
in which the internal path of any tunnels connected to 
computer 158 are stored. As a result, when computer 158 
receives a packet whose policy id indicates that it came 
through a tunnel that ends with computer 158, e.g., tunnel 
140, it decapsulates and decrypts the packet according to the 
policy id and sends the decrypted packet over internal 
network 160 to computer 162 in accordance with the 
decrypted destination address. 

The only addresses visible on the internet and on internal 
network 154 are the addresses of the firewall computers 146, 
148, and 158. The address of internal computer 162 and, 
hence, the network topology of network 160 are protected on 
both the internet and internal network 154. 

The tunnel databases provide the firewall computers 146, 
148, and 158 with information as to the internal path of the 
tunnels. Thus, if computer 162 was another firewall 
computer, computer 146 may modify the destination address 
of packets received on tunnel 140 to be the address of 
computer 162 to cause computer 158 to send the packet 
directly to computer 162 without checking the policy id 
field. 

Encapsulating/decapsulating and encrypting/decrypting 
network packets may require a large portion of a computer's 
processing power. Creating virtual tunnels using the policy 
id field allows the encapsulating/decapsulating and 
encrypting/decrypting of network packets to be spread 
across several computers. For example, computer 146 may 
decapsulate and decrypt network packets destined for com- 
puters connected to internal network 154 while computer 
158 may decapsulate and decrypt network packets destined 
for computers connected to internal networks 154 and 160. 
Similarly, computer 146 may encapsulate and encrypt net- 
work packets sent from computers connected to internal 
network 154 while computer 158 may encapsulate and 
encrypt network packets sent from computers connected to 
internal networks 154 and 160, 

The Kerberos Key Distribution Center components of 
Kerberos Network Authentication System created under 
project Athena at Massachusetts Institute of Technology, 
defines one method of providing computers with secret keys. 
Referring to FIG. 9, computer 130 is termed the "trusted" 
computer, and before computers 132 and 134 may transfer 
encrypted data to each other over network 136, both com- 
puters send a request to trusted computer 130 for a secret 
key. For a more detailed description of the Kerberos Key 
Distribution Center, see RFC1510 (request for comment) 
"Kerberos Network Authentication Service" by J. Kohl & B. 
Neuman, Sept. 10, 1993, which is incorporated by reference. 

Referring back to FIG. 2, to transfer secure (i.e., encap- 
sulated and/or encrypted) network packets between two 
computers, operators of the two computers may verbally 
exchange a secret key for each tunnel between the comput- 
ers and then manually initialize the computers to transfer 
data by generating a tunnel record including a secret key for 
each tunnel between the two computers. Firewall computers 
are typically managed by skilled technicians capable of 
generating tunnel records. Typical users have non-firewall 
computers and may wish to transfer encapsulated/encrypted 
data with a firewall computer. To avoid requiring that a 
typical user generate tunnel records and instead of having a 
separate trusted computer provide secret keys to two 
computers, a firewall computer 16, 18 may provide secret 
keys to other computers. 
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Referring also to FIG. 10, when a user wishes to transfer 
packets between his/her computer and a firewall computer, 
the user requests (step 170) a password (a onetime pad) from 
the firewall operator. The operator then generates (step 172) 
tunnel records for each tunnel over which the user's com- 
puter and the firewall computer may transfer network pack- 
ets. The operator also stores (step 174) the password given 
to the user on the firewall computer. The user installs (step 
176) the security network driver (SND) software on his/her 
computer and runs (step 178) a configuration program. The 
configuration program prompts (step 180) the user for the 
password and sends (step 182) a configuration request to the 
firewall computer. 

The firewall computer identifies (step 184) the user's 
computer as the sender of the request and notifies the user's 
computer of the available tunnels by sending (step 186) the 
complete tunnel records, including secret keys, associated 
with each tunnel to the user's computer. The tunnel records 
are sent through network packets that are encrypted using 
the password and the encryption algorithm. Afterwards, the 
firewall deletes (step 188) the password, and further network 
packets are transmitted between the two computers through 
the available tunnels and encrypted according to the secret 
key associated with each tunnel. 

Referring to FIG. 11, generally, each time the user's 
computer accesses (step 190) the internet, a new internet 
address is assigned. The firewall computer needs to know 
the new address in order to update the tunnel records. To 
notify the firewall computer of the new internet address, 
each time the user's computer accesses the internet, the 
configuration software issues (step 192) a connect request to 
the firewall computer. The firewall computer identifies (step 
194) the computer and may prompt the user for a user name 
and a user password. If the user name and password are 
authorized (step 196), the firewall updates (step 198) the 
tunnel records with the internet address sent as part of the 
connect request. The configuration software also updates 
(step 200) the non-firewall computer's tunnel records with 
the computer's new internet address. 

Other embodiments are within the scope of the following 
claims. 

For example, instead of encapsulating the network pack- 
ets using the swIPe protocol header, other internet security 
algorithms may be used. 

Although the security network driver was described with 
respect to send and receive functions, APIs from different 
manufacturers, for example, Sun™, Inc. and Microsoft™, 
Inc., include a variety functions, and the security network 
driver is designed to respond to each possible function. 

The security network driver may also be simultaneously 
connected to multiple network protocols, e.g., both TCP/IP 
22 and IPX 24, as shown in FIG. 3. 

What is claimed is: 

1. A method of handling network packets, comprising: 
receiving an encrypted network packet from an external 

network at a first computer; and 
determining whether to decrypt the encrypted network 
packet at the first computer or to pass the encrypted 
network packet to a computer on a network that is 
internal with respect to the first computer for decryp- 
tion. 

2. The method of claim 1, further comprising, before 
passing the encrypted network packet to the computer on the 
network that is internal with respect to the first computer 

determining a destination computer for the encrypted 
network packet. 
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3. The method of claim 2, wherein determining a desti- 
nation computer further includes: 

determining whether a source computer that sent the 
encrypted network packet is authorized to send 
5 encrypted network packets to the destination computer. 

4. The method of claim 2, wherein determining a desti- 
nation computer includes: 

examining an index field in a header of the network 
packet. 

10 5. The method of claim 4, wherein the field corresponds 
to a virtual network tunnel. 

6. The method of claim 2, wherein an encrypted network 
packet is passed to the computer on the network that is 
internal with respect to the first computer when the desti- 
nation computer for the encrypted network packet is deter- 

1 mined to be the computer on the network that is internal with 
respect to the first computer. 

7. The method of claim 1, further comprising: 
decrypting an encrypted network packet at the first com- 
puter when the destination computer for the encrypted 

20 network packet is determined to be the first computer. 

8. The method of claim 7, further comprising: 
passing the decrypted network packet to the computer on 

the network that is internal with respect to the first 
computer. 

25 9, The method of claim 1, further comprising: 
encrypting network packets; and 
sending encrypted network packets from the first com- 
puter to the external network. 

10. The method of claim 9, wherein the computer on the 
30 network that is internal with respect to the first computer 

encrypts the network packets, and further comprising: 
passing the encrypted network packets to the first com- 
puter. 

11. The method of claim 1, wherein the first computer 
35 comprises a firewall computer. 

12. The method of claim 1, wherein the external network 
comprises a public network. 

13. A method of handling network packets, comprising 
receiving an encrypted network packet from a public net- 

40 work at a firewall computer; 

determining the destination computer of the encrypted 
network packet by examining a virtual tunnel field that 
corresponds to the method of encryption; 

determining whether a source computer that sent the 
encrypted network packet is authorized to send 
encrypted network packets to the destination computer; 
and 

determining whether to decrypt the encrypted network 
5Q packet at the firewall computer or to pass the encrypted 
network packet to a computer on a network that is 
internal with respect to the first computer for decryp- 
tion. 

14. A method of handling a network packet, comprising 
55 receiving an encrypted network packet at a first computer 

over a network from a source computer; 
examining a field in the network packet to determine 
which of a plurality of encryption algorithms was used 
to encrypt the network packet and to determine a 
60 destination computer for each encrypted network 
packet; and 

decrypting the network packet at the determined destina- 
tion computer. 

15. The method of claim 14, further comprising: 

65 determining whether a source computer that sent each 
encrypted network packet is authorized to send 
encrypted network packets to the destination computer. 
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16. The method of claim 14, further comprising: 
passing encrypted network packets to a computer on an 

internal network when the destination computer is 
determined to be the computer on the internal network. 

17. The method of claim 14, further comprising: 5 
decrypting network packets when the destination com- 
puter is determined to be the first computer. 

18. The method of claim 17, further comprising: 

passing the decrypted network packets to a computer on Q 
an internal network. 

19. The method of claim 14, wherein the field corresponds 
to a virtual network tunnel. 

20. The method of claim 14, wherein the network com- 
prises a public network. 5 

21. The method of claim 14, wherein the first computer 
comprises a firewall computer. 

22. A method of handling an encrypted network packet, 
comprising: 

receiving the encrypted network packet sent over a net- 2 o 

work at a first computer; 
determining which virtual tunnel the network packet was 

sent over; and 

routing the network packet to a destination computer that 
is internal with respect to the first computer in accor- 25 
dance with the determined virtual tunnel. 

23. The method of claim 22, further comprising: 
decrypting each network packet in accordance with the 

determined virtual tunnel. 
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24. A method of handling a network packet, comprising: 

encrypting network packets at a first computer connected 
to an internal network; 

storing a virtual tunnel identifier in the packet that is used 
to determine routing of the packet; 

passing the encrypted network packet over the internal 
network to a public network interface computer; and 

passing the encrypted network packet over a public net- 
work connected to the public network interface com- 
puter. 

25. A method of handling network packets, comprising: 

receiving network packets sent over a network at a first 
computer; 

examining each packet's virtual tunnel field to determine 
which virtual tunnel each network packet was sent over 
and whether a source computer that sent each network 
packet is authorized to send network packets over the 
determined virtual tunnel. 

26. The method of claim 25, further comprising: 

routing each network packet to a destination computer in 
accordance with the determined virtual tunnel when the 
source computer is determined to be authorized. 

* * * * * 
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